Minutes, IBIS Quality Committee

16 June 2009

11-12 AM EST (8-9 AM PST)

ROLL CALL
  Adam Tambone
* Anders Ekholm, Ericsson
  Barry Katz, SiSoft
  Benny Lazer
  Benjamin P Silva
  Bob Cox, Micron
* Bob Ross, Teraspeed Consulting Group
  Brian Arsenault
  David Banas, Xilinx
  Eckhard Lenski, Nokia Siemens Networks
  Eric Brock
* Guan Tao, Huawei Technologies
  Gregory R Edlund
  Hazem Hegazy
  Huang Chunxing, Huawei Technologies
  John Figueroa
  John Angulo, Mentor Graphics
  Katja Koller, Nokia Siemens Networks
  Kevin Fisher
  Kim Helliwell, LSI Logic
  Lance Wang, IOMethodology
  Lynne Green
* Mike LaBonte, Cisco Systems
  Mike Mayer, SiSoft
* Moshiul Haque, Micron Technology
  Muniswarareddy Vorugu, ARM Ltd
* Pavani Jella, TI
  Peter LaFlamme
  Randy Wolff, Micron Technology
  Radovan Vuletic, Qimonda
  Robert Haller, Enterasys
  Roy Leventhal, Leventhal Design & Communications
  Sherif Hammad, Mentor Graphics
  Todd Westerhoff, SiSoft
  Tom Dagostino, Teraspeed Consulting Group
  Kazuyoshi Shoji, Hitachi
  Sadahiro Nonoyama
  Liqun, Huawei

Everyone in attendance marked by *

NOTE: "AR" = Action Required.

-----------------------MINUTES ---------------------------
Mike LaBonte conducted the meeting.

Call for patent disclosure:

- No one declared a patent.

AR Review:

- Mike post new draft
  - 1.1as was posted

- Mike fix font and reference issues in IQ specification identified by Anders
  - TBD

New items:

A Motorola group has contacted Mike asking for a presentation on IBIS Quality
- Bob: They could join our meetings too

Anders Eckholm review of the IQ 1.1 specification (2nd half):

3.1.1.	{LEVEL 2}  [Package] must have typ/min/max values
- We had changed this in the last meeting
- Moshiul: The [Package] min/max L and C do not necessarily correspond
  to any single pin
- Bob: Worst case time delay is max L max C
  - Worst case impedance is max L over min C or min L over max C
  - May use max/max and min/min, but EDA tool can do whatever
  - A good practice is to find min & max of the [Pin] RLC list
- Mike: We use [Package] calculated overall skew to decide when RLC is needed
- Bob: We call for pin RLC in 3.3.2
  - That is a level 3 check

From Anders' email:
    3.1.2 
    here we state pin parasitics should represent the range spanned by the
    actual pin parasitics for signal pins..  Which raises the question which
    return pin these parasitics are suppose to be related to ?  At the end
    of the paragraph it clearly states that power and Gnd pins should not be
    included in the determination of the [Package] parasitics. Related to a
    discussion we had concerning defining pin parasitics for power & Gnd pins.
- Anders: The return path assumption is the problem here
- Bob: This has to be figured out from [Pin Mapping]
- Mike: [Pin Mapping] gives just a loose pin association, is that enough?
- Bob: There can be multiple loops using that same parasitic
  - For example, 5 returns using the same ground
  - A TDR measurement might be measuring the whole loop
- Mike: The ATM group is working on better interconnect modeling now
- Bob: Modeling is always done piecewise anyway
  - IBIS is extraction-centric
- Mike: Should we change 3.1.2?
  - Anders: It is not clear what we could do
- Mike: Is consideration of return paths too much detail for [Package]?
- Bob: If the power and ground pins have zero LC that might have been
  factored into the signal pin RLC
- Anders: There should be a comment about extraction
- Moshiul: With some extraction tools you can not specify return paths.
  - They make assumptions
  - The mounting makes a difference
- Mike: We could delete: "typically it is the average of the signal pin
  parasitics, but it need not be"
  - Also delete: "The power and ground pins should NOT be included in the
    determination of the [Package] parasitics"
  - We could add a comment calling for documentation of the method used
- Moshiul: The limits L < 100nH, C < 100pF, R < 10 ohm are not reasonable
  - for power and ground pins
  - We changed it to apply only to signal pins
- Mike: This IQ check calls for limits lower than IBISCHK
- Bob: It would be better to not have numeric limits
  - But it is OK as is
  - The lower limits might be a CAUTION in future IBISCHK

- No new draft will sent this time as there are few changes

Meeting ended at 12:02 PM Eastern Time.